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Information Model for IP Flow Information Export (IPFIX) 
Abstract 


This document defines the data types and management policy for the 
information model for the IP Flow Information Export (IPFIX) 
protocol. This information model is maintained as the IANA "IPFIX 
Information Elements" registry, the initial contents of which were 
defined by RFC 5102. This information model is used by the IPFIX 
protocol for encoding measured traffic information and information 
related to the traffic Observation Point, the traffic Metering 
Process, and the Exporting Process. Although this model was 
developed for the IPFIX protocol, it is defined in an open way that 
allows it to be easily used in other protocols, interfaces, and 
applications. This document obsoletes RFC 5102. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7012. 
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1. Introduction 


The IP Flow Information Export (IPFIX) protocol serves as a means for 
transmitting information related to network traffic measurement. The 
IPFIX Protocol Specification [RFC7011] defines how Information 
Elements are transmitted and also specifies the encoding of a set of 
basic data types for these Information Elements. However, the list 
of Information Elements that can be transmitted by the protocol, such 
as Flow attributes (source IP address, number of packets, etc.) and 
information about the Metering Process and Exporting Process (packet 
Observation Point, sampling rate, Flow timeout interval, etc.), is 
not specified in [RFC7011]. 


The IANA "IPFIX Information Elements" registry [IANA-IPFIX] is the 
current complete reference for IPFIX Information Elements. The 
initial values for this registry were provided by [RFC5102]. 


This document complements the IPFIX Protocol Specification [RFC7011] 
by providing an overview of the IPFIX information model and 
specifying data types for it. IPFIX-specific terminology used in 
this document is defined in Section 2 of [RFC7011]. As in [RFC7011], 
these IPFIX-specific terms have the first letter of a word 
capitalized when used in this document. 
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The use of the term 'information model’ is not fully in line with the 
definition of this term in [RFC3444], as the IPFIX information model 
does not specify relationships between Information Elements, nor does 
it specify a concrete encoding of Information Elements. For an 
encoding suitable for use with the IPFIX protocol, see [RFC7011]. 
Besides the encoding used by the IPFIX protocol, other encodings of 
IPFIX Information Elements can be applied, for example, XML-based 
encodings. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


1.1. Changes since RFC 5102 


This document obsoletes the Proposed Standard revision of the IPFIX 


information model specification [RFC5102]. The following changes 
have been made to this document with respect to the previous 
document : 


- At the time of this publication, technical and editorial errata 
reported for [RFC5102] have been reviewed and addressed as needed. 


- All references to [RFC5101] have been updated to [RFC7011], 
reflecting changes to [RFC5101]. 


- Information Element definitions have been removed, as the reference 
for these is now [IANA-IPFIX]; a historical note on categorizations 
of Information Elements as defined in [RFC5102] has been retained 
in Section 5. 


- The process for modifying [IANA-IPFIX] has been improved and is now 
described in [RFC7013]; Section 6 has been updated accordingly, and 


a new Section 7.3 provides IANA considerations for this process. 


- Definitions of timestamp data types have been clarified. 


- Appendices A and B have been removed. 
1.2. IPFIX Documents Overview 


The IPFIX protocol provides network administrators with access to 
network flow information. The architecture for the export of 
measured flow information out of an IPFIX Exporting Process to a 
Collecting Process is defined in [RFC5470], per the requirements 
defined in [RFC3917]. The IPFIX Protocol Specification [RFC7011] 
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2. 


defines how IPFIX Data Records and templates are carried via a number 
of transport protocols from IPFIX Exporting Processes to IPFIX 
Collecting Processes. 


Four IPFIX optimizations/extensions are currently specified: a 
bandwidth-saving method for the IPFIX protocol [RFC5473], an 
efficient method for exporting bidirectional flows [RFC5103], a 
method for the definition and export of complex data structures 
[RFC6313], and the specification of the Protocol on IPFIX Mediators 
[IPF IX-MED-PROTO] based on the IPFIX Mediation Framework [RFC6183]. 


IPFIX has a formal description of IPFIX Information Elements -- their 
names, data types, and additional semantic information -- as 
specified in this document. The export of the Information Element 


types is specified in [RFC5610]. 


[RFC6728] specifies a data model for configuring and monitoring 
devices that are IPFIX and Packet Sampling (PSAMP) compliant using 
the Network Configuration Protocol (NETCONF), while [RFC6615] 
specifies MIB modules for monitoring. 


In terms of development, [RFC5153] provides guidelines for the 
implementation and use of the IPFIX protocol, while [RFC5471] 
provides guidelines for testing. 


Finally, [RFC5472] describes what types of applications can use the 
IPFIX protocol and how they can use the information provided. It 
furthermore shows how the IPFIX framework relates to other 
architectures and frameworks. 


Properties of IPFIX Protocol Information Elements 


.1. Information Element Specification Template 


Information in messages of the IPFIX protocol is modeled in terms of 
Information Elements of the IPFIX information model. The IPFIX 
Information Elements mentioned in Section 5 are specified in 
[IANA-IPFIX]. 


All Information Elements specified for the IPFIX protocol MUST have 
the following properties defined: 


name - A unique and meaningful name for the Information Element. 
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elementId - A numeric identifier of the Information Element. If this 
identifier is used without an enterprise identifier (see [RFC7011] 
and the definition of enterpriseld listed below), then it is 
globally unique, and the list of allowed values is administered by 
TANA. It is used for compact identification of an Information 
Element when encoding Templates in the protocol. 


description - The semantics of this Information Element. Describes 
how this Information Element is derived from the Flow or other 
information available to the observer. Information Elements of 
dataType string or octetArray that have length constraints (fixed 
length, minimum and/or maximum length) MUST note these constraints 
in their descriptions. 


dataType - One of the types listed in Section 3.1 of this document or 
registered in the IANA "IPFIX Information Element Data Types" 
subregistry. The type space for attributes is constrained to 
facilitate implementation. The existing type space encompasses 
most primitive types used in modern programming languages, as well 
as some derived types (such as ipv4Address) that are common to 
this domain. 


status - The status of the specification of this Information Element. 
Allowed values are 'current” and 'deprecated”. All newly defined 
Information Elements have ’current’ status. The process for 


moving Information Elements to the 'deprecated” status is defined 
in Section 5.3 of [RFC7013]. 


Enterprise-specific Information Elements MUST have the following 
property defined: 


enterpriseld - Enterprises may wish to define Information Elements 
without registering them with IANA, for example, for enterprise- 


internal purposes. For such Information Elements, the Information 
Element identifier described above is not sufficient when the 
Information Element is used outside the enterprise. If 


specifications of enterprise-specific Information Elements are 
made public and/or if enterprise-specific identifiers are used by 
the IPFIX protocol outside the enterprise, then the enterprise- 
specific identifier MUST be made globally unique by combining it 
with an enterprise identifier. Valid values for the enterpriseld 
are defined by IANA as Structure of Management Information (SMI) 
network management private enterprise numbers, defined at 
[IANA-PEN]. 
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All Information Elements specified for the IPFIX protocol either in 
this document or by any future extension MAY have the following 
properties defined: 


dataTypeSemantics - The integral types are qualified by additional 
semantic details. Valid values for the data type semantics are 
either specified in Section 3.2 of this document or will be 
specified in a future extension of the information model. 


units - If the Information Element is a measure of some kind, the 
units identify what the measure is. 


range - Some Information Elements may only be able to take on a 
restricted set of values that can be expressed as a range (e.g., O 
through 511, inclusive). If this is the case, the valid inclusive 
range SHOULD be specified; values for this Information Element 
outside the range are invalid and MUST NOT be exported. 


reference - Identifies additional specifications that more precisely 
define this item or provide additional context for its use. 


The following two Information Element properties are defined to allow 
the management of an Information Elements registry with Information 
Element definitions that may be updated over time, per the process 
defined in Section 5.2 of [RFC7013]: 


revision - The revision number of an Information Element, starting at 
O for Information Elements at time of definition and incremented 
by one for each revision. 


date - The date of the entry of this revision of the Information 
Element into the registry. 


A template for specifying Information Elements is given in 
Section 9.1 of [RFC7013]. 


2.2. Scope of Information Elements 


By default, most Information Elements have a scope specified in their 
definitions. Within Data Records defined by Options Templates, the 
IPFIX protocol allows further limiting of the Information Element 
scope. The new scope is specified by one or more scope fields and 
defined as the combination of all specified scope values; see 

Section 3.4.2.1 on IPFIX scopes in [RFC7011]. 
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Be de 


Naming Conventions for Information Elements 


The following naming conventions were used for naming Information 
Elements in this document. It is recommended that extensions of the 
model use the same conventions. 


o 


o 


Names of Information Elements SHOULD be descriptive. 


Names of Information Elements MUST be unique within the "IPFIX 
Information Elements" registry [IANA-IPFIX]. Enterprise-specific 
Information Elements SHOULD be prefixed with a vendor name. 


Names of Information Elements MUST start with lowercase letters. 


Composed names MUST use capital letters for the first letter of 
each component (except for the first one). All other letters are 
lowercase, even for acronyms. Exceptions are made for acronyms 
containing a mixture of lowercase and capital letters, such as 
‘'IPv4’ and ‘’IPv6’. Examples are "sourceMacAddress" and 
"destinationIPv4Address". 


Middleboxes [RFC3234] may change Flow properties, such as the 
Differentiated Services Code Point (DSCP) value or the source IP 
address. If an IPFIX Observation Point is located in the path of 
a Flow before one or more middleboxes that potentially modify 
packets of the Flow, then it may be desirable to also report Flow 
properties after the modification performed by the middleboxes. 

An example is an Observation Point before a packet marker changing 
a packet’s IPv4 Type of Service (TOS) field that is encoded in 
Information Element ipClassOfService. Then the value observed and 
reported by Information Element ipClassOfService is valid at the 
Observation Point but not after the packet passed the packet 
marker. For reporting the change value of the TOS field, the 
IPFIX information model uses Information Elements that have a name 
prefix "post", for example, "postIpClassOfService". Information 
Elements with prefix "post" report on Flow properties that are not 
necessarily observed at the Observation Point but that are 
obtained within the Flow’s Observation Domain by other means 
considered to be sufficiently reliable, for example, by analyzing 
the packet marker's marking tables. 
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3. Type Space 


This section describes the abstract data types that can be used for 
the specification of IPFIX Information Elements in Section 4. 
Section 3.1 describes the set of abstract data types. 


Abstract data types unsigned8, unsigned16, unsigned32, unsigned64, 
signed8, signedl6, signed32, and signed64 are integral data types. 
As described in Section 3.2, their data type semantics can be further 
specified, for example, by /’totalCounter’, 'deltaCounter', 
‘identifier’, or 'flags'. 

3.1. Abstract Data Types 
This section describes the set of valid abstract data types of the 
IPFIX information model, independent of encoding. Note that further 
abstract data types may be specified by future updates to this 
document. Changes to the associated IPFIX "Information Element Data 
Types" subregistry [IANA-IPFIX] specified in [RFC5610] require a 
Standards Action [RFC5226]. 
The current encodings of these data types for use with the IPFIX 
protocol are defined in [RFC7011]; encodings allowing the use of the 
IPFIX Information Elements [IANA-IPFIX] with other protocols may be 
defined in the future by referencing this document. 


3.1.1. unsigned8 


The type "unsigned8" represents a non-negative integer value in the 
range of 0 to 255. 


3.1.2. unsignedl6 


The type "unsigned16" represents a non-negative integer value in the 
range of 0 to 65535. 


3.1.3. unsigned32 


The type "unsigned32" represents a non-negative integer value in the 
range of 0 to 4294967295. 


3.1.4. unsigned64 


The type "unsigned64" represents a non-negative integer value in the 
range of 0 to 18446744073709551615. 
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3.1.5. signed8 


The type "signed8" represents an integer value in the range of -128 
oral 27 


3.1.6. signedl6 


The type "signedl6" represents an integer value in the range of 
-32768 to 32767. 


3.1.7. signed32 


The type "signed32" represents an integer value in the range of 
-2147483648 to 2147483647. 


3.1.8. signed64 


The type "signed64" represents an integer value in the range of 
-9223372036854775808 to 9223372036854775807. 


3.459% “float 32 


The type "float32" corresponds to an IEEE single-precision 32-bit 
floating-point type as defined in [IEEE.754.2008]. 


3.1.10. float64 


The type "float64" corresponds to an IEEE double-precision 64-bit 
floating-point type as defined in [IEEE.754.2008]. 


3.1.11. boolean 


The type "boolean" represents a binary value. The only allowed 
values are "true" and "false". 


3.1.12. macAddress 


The type "macAddress" represents a MAC-48 address as defined in 
[IEEE.802-3.2012]. 


3.1.13. octetArray 


The type "octetArray" represents a finite-length string of octets. 
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3.1.14. string 
The type "string" represents a finite-length string of valid 
characters from the Unicode coded character set [ISO.10646]. Unicode 
incorporates ASCII [RFC20] and the characters of many other 
international character sets. 


3.1.15. dateTimeSeconds 


The type "dateTimeSeconds" represents a time value expressed with 
second-level precision. 


3.1.16. dateTimeMilliseconds 


The type "dateTimeMilliseconds" represents a time value expressed 
with millisecond-level precision. 


3.1.17. dateTimeMicroseconds 


The type "dateTimeMicroseconds" represents a time value expressed 
with microsecond-level precision. 


3.1.18. dateTimeNanoseconds 


The type "dateTimeNanoseconds" represents a time value expressed with 
nanosecond-level precision. 


3.1.19. ipv4Address 

The type "ipv4Address" represents an IPv4 address. 
3.1.20. ipvéAddress 

The type "ipvéAddress" represents an IPv6 address. 
3.1.21. basicList 


The type "basicList" supports structured data export as described in 
[RFC6313]; see Section 4.5.1 of that document for encoding details. 


3.1.22. subTemplateList 
The type "subTemplateList" supports structured data export as 


described in [RFC6313]; see Section 4.5.2 of that document for 
encoding details. 
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3.1.23. subTemplateMultiList 


The type "subTemplateMultiList" supports structured data export as 
described in [RFC6313]; see Section 4.5.3 of that document for 
encoding details. 


3.2. Data Type Semantics 


This section describes the set of valid data type semantics of the 
IPFIX information model. A subregistry of data type semantics 
[IANA-IPFIX] is established in [RFC5610]; the restrictions on the use 
of semantics below are compatible with those specified in 

Section 3.10 of that document. These semantics apply only to numeric 
types, as noted in the description of each semantic below. 


Further data type semantics may be specified by future updates to 


this document. Changes to the associated "IPFIX Information Element 
Semantics" subregistry [IANA-IPFIX] require a Standards Action 
[RFC5226]. 


3.2.1. quantity 


"quantity" is a numeric (integral or floating point) value 
representing a measured value pertaining to the record. This is 
distinguished from counters that represent an ongoing measured value 
whose "odometer" reading is captured as part of a given record. This 
is the default semantic type of all numeric data types. 


3.2.2. totalCounter 


"totalCounter" is an integral value reporting the value of a counter. 
Counters are unsigned and wrap back to zero after reaching the limit 
of the type. For example, an unsigned64 with counter semantics will 
continue to increment until reaching the value of 2**64 - 1. At this 
point, the next increment will wrap its value to zero and continue 
counting from zero. The semantics of a total counter is similar to 
the semantics of counters used in the Simple Network Management 
Protocol (SNMP), such as Counter32 as defined in [RFC2578]. The only 
difference between total counters and counters used in SNMP is that 
the total counters have an initial value of 0. A total counter 
counts independently of the export of its value. 


3.2.3. deltaCounter 


"deltaCounter" is an integral value reporting the value of a counter. 
Counters are unsigned and wrap back to zero after reaching the limit 
of the type. For example, an unsigned64 with counter semantics will 
continue to increment until reaching the value of 2**64 - 1. At this 
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point, the next increment will wrap its value to zero and continue 
counting from zero. The semantics of a delta counter is similar to 
the semantics of counters used in SNMP, such as Counter32 as defined 
in [RFC2578]. The only difference between delta counters and 
counters used in SNMP is that the delta counters have an initial 
value of 0. A delta counter is reset to 0 each time it is exported 
and/or expires without export. 


3.2.4. identifier 


"identifier" is an integral value that serves as an identifier. 
Specifically, mathematical operations on two identifiers (aside from 
the equality operation) are meaningless. For example, Autonomous 
System ID 1 * Autonomous System ID 2 is meaningless. Identifiers 
MUST be one of the signed or unsigned data types. 


3.2.5. flags 


"flags" is an integral value that represents a set of bit fields. 
Logical operations are appropriate on such values, but other 
mathematical operations are not. Flags MUST always be of an unsigned 
data type. 


4. Information Element Identifiers 


All Information Elements defined in the IANA "IPFIX Information 
Elements" registry [IANA-IPFIX] have their identifiers assigned 
by IANA. 


The values of these identifiers are in the range of 1-32767. Within 
this range, Information Element identifier values in the sub-range of 
1-127 are compatible with field types used by NetFlow version 9 
[RFC3954] for historical reasons. 


In general, IANA will add newly registered Information Elements to 
the registry, assigning the lowest available Information Element 
identifier in the range of 128-32767. 


Enterprise-specific Information Element identifiers have the same 
range of 1-32767, but they are coupled with an additional enterprise 
identifier. For enterprise-specific Information Elements, 
Information Element identifier 0 is also reserved. Enterprise- 
specific Information Element identifiers can be chosen by an 
enterprise arbitrarily within the range of 1-32767. The same 
identifier may be assigned by other enterprises for different 
purposes; these Information Elements are distinct because the 
Information Element identifier is coupled with an enterprise 
identifier. 
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Enterprise identifiers are to be registered as SMI network management 
private enterprise code numbers with IANA. The registry can be found 
at [IANA-PEN]. 


5; Information Elements 


[IANA-IPFIX] is now the normative reference for IPFIX Information 
Elements. When [RFC5102] was published, it defined, in its 
Section 5, the initial contents of that registry. 


As a historical note, Information Elements (IEs) were organized into 
categories in [RFC5102] according to their semantics and their 
applicability; these categories were not carried forward into 
[IANA-IPFIX] as an organizing principle. The categories (with 
example IEs) were: 


1. Identifiers (e.g., ingressInterface) 
2. Metering and Exporting Process Configuration 

(e.g., exporterlPv4Address) 
3. Metering and Exporting Process Statistics 

(e.g., exportedOctetTotalCount) 
4 IP Header Fields (e.g., sourcelPv4Address) 
5. Transport Header Fields (e.g., sourceTransportPort) 
6. Sub-IP Header Fields (e.g., sourceMacAddress) 
7 Derived Packet Properties (e.g., bgpSourceAsNumber) 
8. Min/Max Flow Properties (e.g., minimumIpTotalLength) 
9. Flow Timestamps (e.g., flowStartTimeMilliseconds) 
10. Per-Flow Counters (e.g., octetDeltaCount) 
11. Miscellaneous Flow Properties (e.g., flowEndReason) 
12. Padding (paddingOctets) 


Information Elements derived from fields of packets or from Packet 
Treatment can typically serve as Flow Keys used for mapping packets 
to Flows. These Information Elements were placed in categories 4-7 
in the original categorization. 


Information Elements not serving as Flow Keys may have different 
values for each packet in a Flow. For Information Elements with 
values derived from fields of packets or from Packet Treatment, and 
for which the value may change from packet to packet within a single 
Flow, the exported value of an Information Element is by default 
determined by the first packet observed for the corresponding Flow; 
the description of the Information Element may, however, explicitly 
specify different semantics. This simple rule allows the writing of 
all Information Elements related to header fields once, when the 
first packet of the Flow is observed. For further observed packets 
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of the same Flow, only Flow properties that depend on more than one 
packet need to be updated; these Information Elements were placed in 
categories 8-11 in the original categorization. 


Information Elements with a name having the "post" prefix (e.g., 
postIpClassOfService) do not necessarily report properties that were 
actually observed at the Observation Point but may be retrieved by 
other means within the Observation Domain. These Information 
Elements can be used if there are middlebox functions within the 
Observation Domain changing Flow properties after packets passed the 
Observation Point; they may also be reported directly by the 
Observation Point if the Observation Point is situated where it can 
observe packets on both sides of the middlebox. 


6. Extending the Information Model 


A key requirement for IPFIX is to allow for extension of the 
Information Model via the "IP Flow Information Export (IPFIX) 
Entities" registry [IANA-IPFIX]. New Information Element definitions 
can be added to this registry subject to Expert Review [RFC5226], 
with additional process considerations as described in [RFC7013]; 
that document also provides guidelines for authors and reviewers of 
new Information Element definitions. 


For new Information Elements, the type space defined in Section 3 can 
be used. If required, new abstract data types can be added to the 
"IPFIX Information Element Data Types" subregistry [IANA-IPFIX] as 
defined in [RFC5610]. New abstract data types and semantics are 
subject to Standards Action [RFC5226] and MUST be defined in IETF 
Standards Track documents updating this document. 


Enterprises may wish to define Information Elements without 
registering them with IANA. IPFIX explicitly supports enterprise- 
specific Information Elements. Enterprise-specific Information 
Elements are described in Sections 2.1 and 4; guidelines for using 
them appear in [RFC7013]. 


7. IANA Considerations 


As this document obsoletes [RFC5102], IANA has updated the references 
in the "IP Flow Information Export (IPFIX) Entities" registry 
[IANA-IPFIX], the "IPFIX MPLS label type" subregistry of that 
registry, the urn:ietf:params:xml:ns:ipfix-info XML namespace, and 
the urn:ietf:params:xml:schema:ipfix-info XML schema to refer to this 
document. 
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However, [RFC5102] still provides a historical reference for the 
initial entries in the "IPFIX Information Elements" registry. 
Therefore, IANA has kept [RFC5102] as the requestor of those 
Information Elements in the "IPFIX Information Elements" registry 
that list [RFC5102] as their requestor and added the following 
explanatory note to the "IPFIX Information Elements" registry: 


"RFC 7012 has obsoleted RFC 5102; references to RFC 5102 in this 
registry remain as part of the historical record". 


The Information Element Specification Template (Section 2.1) requires 


two new columns not present in [RFC5102]. IANA has created a new 
Revision column in the "IPFIX Information Elements" registry and set 
the Revision of existing Information Elements to 0. IANA has also 


created a new Date column in that registry and set the Date of all 
existing Information Elements to the publication date of this 
document. 


To identify Information Elements with identifiers 127 or below as 
NetFlow version 9 [RFC3954] compatible, IANA has set the Name of all 
existing Reserved Information Elements with identifier 127 or less to 
"Assigned for NetFlow v9 compatibility" and the Reference of those 
Information Elements to [RFC3954]. 


As IANA now has change control of the schema used for the IANA "IPFIX 
Information Elements" registry [IANA-IPFIX], IANA has deprecated the 
previous XML schema for the description of Information Elements 
urn:ietf:params:xml:schema:ipfix-info [IPFIX-XML-SCHEMA]. 


To support the process described in Section 7.4, IANA has established 
a mailing list for communicating with the IE-DOCTORS, named 
ie-doctors@ietf.org. 


The remaining subsections of this section contain no actions 
for IANA. 


ados IPFIX Information Elements 


This document refers to Information Elements, for which the Internet 
Assigned Numbers Authority (IANA) has created the IPFIX "Information 
Elements" registry [IANA-IPFIX]. The columns of this registry must, 
at minimum, be able to store the information defined in the template 
detailed in Section 2.1; it may contain other information as 
necessary for the management of the registry. 


The process for making additions or other changes to the "IPFIX 
Information Elements" registry is given in Section 7.4. 
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7.2. MPLS Label Type Identifier 


Information Element #46, named mplsTopLabelType, carries MPLS label 
types. Values for 5 different types have initially been defined. 

For ensuring the extensibility of this information, IANA has created 
a new subregistry for MPLS label types and filled it with the initial 
list from the description Information Element #46, mplsTopLabelType. 


New assignments for MPLS label types are administered by IANA through 
Expert Review [RFC5226], i.e., review by one of a group of experts 
designated by an IETF Area Director. The group of experts must 
double-check the label type definitions with already-defined label 
types for completeness, accuracy, and redundancy. The specification 
of new MPLS label types MUST be published using a well-established 
and persistent publication medium. 


7.3. XML Namespace and Schema 


The prior version of this document [RFC5102] specified an XML schema 
for IPFIX Information Element definitions [IPFIX-XML-SCHEMA] that was 
used in the generation of the document text itself. When the IANA 
"IPFIX Information Elements" registry [IANA-IPFIX] was created, 
change control on the registry and the schema used to validate it 
passed to IANA. 


The use of a machine-readable syntax for the registry enables the 
creation of IPFIX tools that can automatically adapt to extensions to 
the information model. It should be noted that the use of XML in 
Exporters, Collectors, or other tools is not mandatory for the 
deployment of IPFIX. In particular, Exporting Processes do not 
produce or consume XML as part of their operation. IPFIX Collectors 
MAY take advantage of the machine-readability of the information 
model versus hard-coding their behavior or inventing proprietary 
means for accommodating extensions. However, in order to avoid 
unnecessary load on the IANA infrastructure serving the registry, 
Collectors SHOULD NOT poll the IANA registry [IANA-IPFIX] directly at 
runtime. 


The reference to the current schema is embedded in the registry 
[IANA-IPFIX]; this schema may change from time to time as necessary 
to support the maintenance of the registry. As such, the schema 
urn:ietf:params:xml:schema:ipfix-info [IPFIX-XML-SCHEMA] specified in 
[RFC5102] has been deprecated. 
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7.4. Addition, Revision, and Deprecation 


New assignments for the "IPFIX Information Elements" registry are 
administered by IANA through Expert Review [RFC5226]. These experts 
are referred to as IE-DOCTORS and are appointed by the IESG. The 
process they follow is defined in [RFC7013]. 


Information Element identifiers in the range of 1-127 are compatible 
with field types used by NetFlow version 9 [RFC3954] for historical 
reasons and must not be assigned unless the Information Element is 
compatible with the NetFlow version 9 protocol, as determined by one 
of the IE-DOCTORS designated by the IESG as a NetFlow version 9 
expert. 


Future assignments added to the "IPFIX Information Elements" registry 
that require subregistries for enumerated values (e.g., Section 7.2) 
must have those subregistries added simultaneously with the new 
assignment; additions to these subregistries must be subject to 
Expert Review [RFC5226]. Unless specified at assignment time, the 
experts for the subregistry will be the same as for the "IPFIX 
Information Elements" registry as a whole. 


When IANA receives a request to add, revise, or deprecate an 
Information Element in the "IPFIX Information Elements" registry, it 
forwards the request to the IE-DOCTORS for review. 


When IANA receives an approval for a request to add an Information 
Element definition from the IE-DOCTORS, it adds that Information 
Element to the registry. The approved request may include changes 
made by the requestor and/or reviewers as compared to the original 
request. 


When IANA receives an approval for a request to revise an Information 
Element definition from the IE-DOCTORS, it changes that Information 
Element’s definition in the registry and updates the Revision and 
Date columns as appropriate. The approved request may include 
changes from the original request. If the original Information 
Element was added to the registry with IETF consensus (i.e., was 
defined by an RFC), the revision will require IETF consensus as well. 


When IANA receives an approval for a request to deprecate an 
Information Element definition from the IE-DOCTORS, it changes that 
Information Element’s definition in the registry and updates the 
Revision and Date columns as appropriate. The approved request may 
include changes from the original request. If the original 
Information Element was added to the registry with IETF consensus 
(i.e., was defined by an RFC), the deprecation will require IETF 
consensus as well. 
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8. Security Considerations 


The IPFIX information model itself does not directly introduce 
security issues. Rather, it defines a set of attributes that may, 
for privacy or business issues, be considered sensitive information. 


For example, exporting values of header fields may make attacks 
possible for the receiver of this information; this would otherwise 
only be possible for direct observers of the reported Flows along the 
data path. 


The underlying protocol used to exchange the information described 
here must therefore apply appropriate procedures to guarantee the 
integrity and confidentiality of the exported information. These 
protocols are defined in separate documents, specifically the IPFIX 
protocol document [RFC7011]. 
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